Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Replace Bouncy Castle package #7124

Merged
merged 2 commits into from
Jun 3, 2024
Merged

Replace Bouncy Castle package #7124

merged 2 commits into from
Jun 3, 2024

Conversation

rubo
Copy link
Contributor

@rubo rubo commented Jun 2, 2024 •
edited
Loading

Changes

  • Replaced the Portable.BouncyCastle package with the latest official BouncyCastle.Cryptography one as per @flcl42 request
  • As a result, removed and replaced our AesEngineX86Intrinsic with the one of Bouncy Castle that already has the improvements from @benaadams
  • Removed Pyroscope as referencing it doesn't have any effect

Types of changes

What types of changes does your code introduce?

  • Bugfix (a non-breaking change that fixes an issue)
  • New feature (a non-breaking change that adds functionality)
  • Breaking change (a change that causes existing functionality not to work as expected)
  • Optimization
  • Refactoring
  • Documentation update
  • Build-related changes
  • Other: Description

Testing

Requires testing

  • Yes
  • No

If yes, did you write tests?

  • Yes
  • No

Remarks

Benchmarks of replacing AesEngineX86Intrinsic (BenchmarkAdams):

| Method         | Mean     | Error    | StdDev    | Median   |
|--------------- |---------:|---------:|----------:|---------:|
| DotnetOSNative | 73.51 ns | 7.217 ns | 21.280 ns | 56.19 ns |
| BenchmarkAdams | 33.40 ns | 2.735 ns |  8.065 ns | 29.45 ns |
| BouncyCastle   | 24.45 ns | 0.491 ns |  0.504 ns | 24.56 ns |

The results differ slightly on each run, but BouncyCastle and BenchmarkAdams are always nearly the same, with BouncyCastle being slightly faster. In the run above, it's noticeably faster. Regarding OS native implementation, I suspect that it doesn't use hardware acceleration, and that may be because of the configuration the .NET runtime invokes it with. But that's just a guess.

@benaadams
Copy link
Member

  • Removed Pyroscope as referencing it doesn't have any effect

Is to have the dll on the otherside so that it can be switched on in graphana if desired; otherwise you'd need a custom docker container on top of our container to include it

@benaadams
Copy link
Member

benaadams commented Jun 2, 2024 •
edited
Loading

Regarding OS native implementation,

The runtime plays it very safe and conservative with their cyrptography use and entirely depends on which native version you have installed at platform level, and are very resistant to any optimizations in that area (i.e. they don't want any responsibility for encryption)

@rubo
Copy link
Contributor Author

rubo commented Jun 2, 2024

The runtime plays it very safe...

Yeah, I know their approach to that. I'm wondering why the OS native implementation doesn't use hardware acceleration; otherwise, it wouldn't be that slower than the other two. So, I assume it could be that the .NET runtime invokes either unoptimized (as you said, conservative) versions or doesn't pass some parameters to turn hardware acceleration on. But that's just a speculation; I haven't checked the code.

@rubo rubo merged commit 519ff42 into master Jun 3, 2024
68 checks passed
@rubo rubo deleted the feature/bouncycastle branch June 3, 2024 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@flcl42 flcl42 flcl42 approved these changes

@benaadams benaadams benaadams approved these changes

@LukaszRozmej LukaszRozmej LukaszRozmej approved these changes

Assignees
No one assigned
Labels
cryptography
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@rubo @benaadams @flcl42 @LukaszRozmej